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PoMT OF Sale Check Service 



5 This application claims priority of U.S. provisional patent application No. 60/225,566 

filed August 14, 2000, of provisional patent application No. 60/227 J12 filed August 24, 2000, 
of provisional patent application No, 6O/27O58 83 filed February 22, 2001 and of utility 
application No. 09/810,945 filed March 15, 2001 which are all hereby incorporated by 
reference, 

10 FIELD OF THE IN\^ENTION 

The present invention relates generally to financial transactions. More specifically, the 

present invention relates to an online, reai-time point-of-sale check authorization system. 

BACKGROUND OF THE BWENTION 

Paper checks count for over 50% of U.S. personal consumption expenditures. The 

15 handling and processing cost of paper checks at the point of sale, as well as the costs and 
losses associated with cliecks, presents significant loss to merchants and the depository 
institutions who accept these checks. In 1999 alone, consumers wrote an estimated 19 billion 
checks at the point of sale. Check handling costs and losses for merchants are estimated at 
$23 billion per year and in 1999 this was an average of more then $1.00 for every check 

20 written at the point of sale. Some estimates place bank costs for processing checks at close to 
20% of non-interest expense.. 

For banks, these check processing costs are the single largest segment of non-interest 
related expense, totalmg more than $40 billion in cost for all checks and approximately $11 
billion dollars for point-of-sale checks alone. Merchants spend about $10 billion in 
25 acceptance and deposits of paper checks. Merchants' losses from acceptance of checks, with 
fi-aud and other reasons, total more than $12 billion dollars. 

In today's merchant market, check authorizations are performed by a host of third-party, 
non-bank competitors who authorize checks using various combinations of negative-file and 
credit-bureau positive information often in conjunction with neural models, to advise 
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merchant clients of the likelihood that a check will clear the settlement process once it is 
posted. The third-party mfonnation S3^tem uses check and coi^umer accoxmt data without 

paying banks for that data. These third-party check authorizers have also begun pilot offerings 
in which the paper check is truncated at the point of sale and converted into an ACH item for 
5 settlement. 

Although there are notable advances in the prior art, the available references do not 
provide an adequate solution to the cost and difficulty of processing paper checks. Most 
relevant references are U.S. Patent Nos. 5,832,463, 5,703,344 and 5,175,682. 

U.S, Patent No, 5:832,463 discloses a system for the real-time conversion of ch^ks 
10 issued by a participating bank or through an Automated Clearing House (ACH) transfer. This 
system is inapphcable for participating drawee banks. For non-participating banks, a paper 
check must be processed. The system is closed and only handles checks from institutions that 
are part of the EDS system. This system is for Conversion Only; the system does not teach or 
suggest the real-time verification or guarantee of checks at the point of sale. 

15 U,S. Patent No. 5,703,344 discloses a real-time, point-of-sale check confirmation and 

guarantee system that uses VisaNet for checks issued by member or non-member third-party 
institutions. This system does not involve check conversion and only discloses batch 
processing of checks. Further, this system does not disclose real-time check conversions, 

U.S. Patent No. 5,175,682 discloses a system of processing checks by verifying and 
20 converting in either batch mode or in real-time if certain predefined circumstances are present. 
There is no online access to demand deposit accoimts nor online, real-time access for any 
bank. The system does not disclose the real-time guarantee of any personal checks, 

U.S. Patent No. 5,053,607 discloses a point-of-sale device only and has no details 
concerning a payment infirastracture. U.S. Patent No. 5,532,464 discloses an electronic check 

25 presentment system but still involves the processing of a paper check. U.S . Patent No. 

6,006,208 discloses a system for making a payment by telephone. U.S. Patent No. 5,484,988 
discloses check clearing through an ACH transaction which is batch driven and not in real- 
time. Further, conversions are not performed online, in real-time agamst any possible bank. 
U.S. Patent No. 5,963,219 discloses a system for generating electronic checks. There are no 

30 paper checks involved at all and there is no conversion of paper checks occurring. 
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It is desirable then for a point-of-sale check service to be able to authorize checks online 
and in real-time for any possible bank upon which a check is drawn. 
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SUMMARY OF THE INVENTION 

To achieve the foregoing, and in accordance with the purpose of the present invention, a 
POS (point of sale) Check Service is disclosed that converts paper checks online and in real- 
time into an electronic funds transaction. This service will significantly reduce paper check 
5 processing costs for member banks and merchants. Advantageously, the service accepts any 
paper personal check from any bank, and authorizes it online, in real-time at the point of sale. 
The paper check is returned to the consumer for his or her records. It is not necessary for the 
merchant to keep the paper check. 

The service operates in real-time over a data communications network and does not need 
10 to rely upon voice communications. Also, unlike a typical ACH transaction which may take 

48 hours, check authorization can occur in a matter of seconds. No PIN (personal 
identification number) is required to be entered, and the system can process a check from a 
participating bank or from a non-participating bank. 

It is estimated that by routing and processing electronic check transactions, banks and 
15 merchants will eliminate billions of dollars in amiual paper check handling costs. Thus, a 
benefit of the POS Check Service is significantly reducing paper check processing costs fox 
banks and merchants. For acquiring banks, the POS Check Service leverages existing 
payment networks and infrastmcture and adds a new source of revenues for all points of sale. 
For a merchant, the POS Check Service lowers the cost of check processing, reduces risk 
20 because paper check handling is eliminated, speeds customer checkout, provides more 

efficient clearing and settlement, reduces losses by providing options for check guaraatee or 
verification, and lowers check losses by retrieving online check authorizations directly from 
the bank on which the check is diswn. For a participating drawee bank, the POS Check 
Service provides an opportunity^ to authorize checks, allows use of existing infrastmcture to 
25 convert paper checks to electronic transactions, and greatly reduces the cost of processing 
checks. For the customer who writes the check, the POS Check Service provides transaction 
details that can be included on a monthly bank statement, enables faster checkout, retrnns the 
voided check and sales draft receipt to the customer, and also improves security because the 
check is returned to the customer at the time of the transaction. 

4 
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BRffiF DESCRIPTION OF THE DRAWINGS 

The invention, together with fiirther advantages thereof may best be understood by 
reference to the following description taken in conjunction with the accompanying drawings in 
which: 

5 FIG. 1 illustrates an embodiment of the POS Check Service authorization and cle:aring 

system. 

FIG. 2 is a flow diagram describing the overall POS Check Service flow. 

FIG. 3 is a flow diagram describing the setup procedures for the POS Check Servii^. 

FIG. 4 is a more detailed illustration of a paper check, 

10 FIG 5 is a flow diagram describing how a request is initiated to convert a check at the 

point of sale, 

FIGS, 6 A, 6B and 6C are a flow diagram describing the authorization and clearing of a 

transaction. 

FIG. 7 is flow diagram describing the completion of a transaction at the point of sale. 

15 FIG. 8 illustrates an example of a transaction receipt printed at the point of sale, 

FIG. 9 is a flow diagram describing the settlement of transactions. 

FIG 10 illustrates the settlement process for transac-aons settled via the service 
organization or switch. 

FIG. 1 1 illustrates the settlement process for POS Check Service transactions via the 

20 ACH. 

FIG. 12 illustrates a settlement flow for a participating drawee bank. 

FIG. 13 illustrates a settlement flow for a non-participating drawee bank. 

FIG. 14 illustrates an altemative settlement flow for a non-participating drawee bank. 
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FIG. 1 5 illustrates an example of an authorization and settlement flow in which the 
acquirer and the drawee bank are the same. 

FIG. 16 is an example of an authorization flow in which the acquiring bank is not the 
same as the drawee bank. 

5 FIG. 1 7 is an example of an authorization flow in which the customer's check is to be 

drawn on a bank which does not participate m the POS Check Service. 

FIG. 1 8 is an example of an activity report for a participatmg drawee bank. 

FIG. 19 illustrates a telecommxmications network suitable for implementing an 
embodiment of the present invention. 

10 FIG, 20 illustrates systems housed within an interchange center to provide online and 

offline transaction processing. 

FIG. 21 illustrates another view of the components of the teleconmiunications network. 

FIG. 22 illustrates in more detail a suitable hardware embodiment for the POS Check 
Service. 

15 FIGS. 23A and 23B illustrate a computer system suitable for hnplementing 

embodiments of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

A merchant first initiates a POS Check Service transaction by entering tiie amount of the 
sale and by passing the check through a reader to electronically capture checking account data 
from the magnetic ink character recognition (MICR) line encoded on the customer's check. 

5 The merchant can optionally key enter customer identification information, such as a driver's 
license nimiber, at the point of sale. The check data, identification data and sale amount are 
combined with other data elements and forwarded to a service organization for processing. As 
another option, the merchant decides whether to send all transactions throu^ tiie S ervice or 
only participating transactions through the Service. For a merchant opting to send only 
10 participating transactions through the Service, flie service organization may distribute routing 
tables which the merchant can use to identify participating transactions. These transactions 
would be cleared and settled through the service organization. In this ii^tence, these 
transactions would never be routed through the ACH. 

The service begins by swiping the check through a check reader at the point of sale. The 
15 transaction is formatted into a check authorization message and one of three service options is 
selected automatically or manually: Conversion Only; Verification with Conversion; or 

Guarantee with Conversion. Under Conversion Only the transaction is approved or declinoi 
without the requkement of account verifioatioB processing, and the merchant retains the risk 
of loss. Under Verification with Conversion, the check authorization message is routed to the 
20 participating drawee bank or to a third-party a^Ithorizing agent fox vmfication of the 

probability that the check wiE be paid. The authorizing agent can accept or decline based on 
access to tiie demand d^osit account (DDA) and/or the third-party risk management database. 
Again, the merchant retains ttie risk of loss. 

Under Guarantee with Conversion, the ch^k authorization request message is routed to 
25 the participating drawee bank or to a third-party authorizing agent to guarantee the check. A 
check guarantor effectively buys the check from the merchant at a discount, ehminating the 
risk of loss to the merchant. The guarantor makes an accept or decline decision, based on 
access to the DDA account and/or to a third-party risk management database. The guarantor 
bears the risk of loss. 

30 
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fflGH LEVEL SYSTEM DESCRIPTION 

FIG. 1 illustrates POS Check Service authorization and clearing system 100. System 
100 is used to convert a paper check at the point of sale into an electronic transaction and to 
authorize and clear the check. Customer 102 wishes to perfonn a transaction with a merchant 
5 104 using a paper check 106. Merchant 104 is any entity that accepts consumer checks in 
payment for merchandise or services. Check 106 is any suitable paper personal check 
presented to a merchant in payment for a purchase. Check 106 may be completely filled out 
by the customer or it may be completely blank, having only identifying characters along its 
lower edge for reading by a device. Although check 106 may be any suitable paper check, 

10 under current NACHA (National Automated Clearing House Association) rules, certain 

checks may not legally be used, although technically their use is fe^ible. For example, under 
NACHA rales, checks such as corporate checks, government checks^ traveler's chocks, checks 
not linked to an ABA demand deposit account, checks drawn on invalid ABA numbers, etc., 
are not currently accepted within the system. Notwithstanding the above, it is contemplated 

15 that as rules are changed, the system may accept additional types of checks. 

Present at the point the sale are any number of devices that assist the merchant with 
reading infomiation from the check and with acquiring information from the customer. 
Preferably, a MICR (magnetic ink character recognition) device 1 10 is used to read identifying 
information from check 1 06. Alternatively, other devices may be used to either read 

20 information from the check or to receive identifying infomiation needed to identify the 

checking account from which the customer wishes money to be withdrawn. For example, an 
OCR device 1 12 may be used to read information from check 106. In other embodiments, 
check 106 is not present and the customer presents other suitable unique information to 
identify the checking account from which he or she wishes money to be withdrawn. For 

25 example, biometrics reader 114 may be used to uniquely identify the customer and a particular 
checking account, and checking account information would be contained at a central database. 
A convemoncc card is another way to link an accoimt number to a consumer. 

Further keypad 108 may be used by the merchant or customer to enter not only 
identifying information for the checking account, but also information concerning the 
30 transaction amoimt and any other customer identifying information. Keypad 108 maybe 

combined with any of devices 1 10-1 14, may be incorporated into a cash register, may be part 

8 
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of a computer, or may be a standalone device. In a preferred embodiment the merchant 
swipes check 106 through MICR device 110 which is incorporated into a c^h register. 

AcquiilBg bank 120 is a financial institution that contracts with the merchant and 
directly or indirectly submits check transactions for authorization, clearing and settlement. A 

5 processor may also perform these fimctions on behalf of the acquirer — both are hereinafter 
refeired to as the acquirer or the acquiring bank. Service organization 122 (also termed the 
"switch" is a financial service organization that accepts messages firom acquirer 120 and routes 
them to either draw^ee bank 124 or to third party 126. Service organization 122 may be any 
suitable organization for performing clearing and settlement such as MasterCard, American 

10 Express, Discover, etc. In a preferred embodiment, service organization 122 is Visa U.S.A. 
Inc. of San Francisco, California, 

Drawee bank 124 is a customer bank tiiat is participating in the POS Check Service and 
is connected online via a network to service organization 122. The drawee bank is where the 
customer maintairis his or her checking account, and the bank issues checks to the customer. 

15 Alternatively, a processor may act on behalf of the drawee bank — both are referred to 

hereinafter as the drawee bank. Third-party authorizing agent 126 is an entity that authorizes 
POS Check Service transactions for non-participating banks and creates the corresponding 
ACH transaction. 

FIG. 2 is a flow diagram describing the overall POS Check Service flow. Initially, 
20 various setup procedures are preformed by or for the merchant, the acquirer, the drawee bank, 
the third party and the service organization. These steps typically occur before the semce is 
operational and before a customer performs a transaction. A customer presents a paper check 
as part of step 154 in which a request is initiated for clearing and settlement; this step is 
explained in greater detail below. 

25 in step 158 system 100 performs authorization and clearing of the transaction in order to 

indicate to the merchant whether the transaction is authorized or not; this step is explained in 
greater detail below. In step 162 the transaction is completed at the point of sale depending 
upon the results returned. Finally, the transaction is settled in step 166 betw€^n the acquirer 
and eitiier the participating drawee bank or a non-participating bank. 

30 
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DETAILED FLOW DESCRIPTION 

FIG. 3 is a flow diagram describing the setup procMures for the POS Check Service. 
The setup procedures typically occur before the POS Check Service is available to conduct a 
transaction. Regarding the point of sale, there are various tasks a merchant performs in order 
5 to be ready to convert a check at the point of sale. For example, a merchant installs devices at 

the point of sale that can read MICR, OCR or other data on checks, installs terminals that 
allow key entry of any additional data, and installs devices for printing a sales draft receipt and 
to initiate reversals. A merchant also develops or installs a point-of-sale apphcation for use 
with a check reader that can read and assemble the required information for transmission. 

10 Development of these apphcation programs is knov^Ti to those of skill in the art. A merchant 
also designates a bank account where electronic check funds can be deposited. Depending 
upon the telecommunications service used, the merchant works with its acquirer to order and 
install the required telecommunications configuration, and also works with its acquirer to 
agree on the settlement process and reconfiguration procedures. The merchant also works 

15 with a third party agent to set up parameters for velocity checks (which may also be handled 
by an acquirer), sets up service options, and performs customer education and clerk training. 

The acqmrer also performs certain tasks to enable POS Check Service transactions. For 

example, the acquirer provides hardware and software for communication with a merchant and 

a service organization which includes the ability to receive, reformat and send POS Check 
20 Service transactions. The acquirer also provides a unique merchant identifier for each 

merchant name and location that originates transactions. The acquirer also selects service 
options to be supported, etc. 

A participating drawee bank is enabled to receive and respond to POS Check Service 
transactions. Also, the drawee bank is enabled to receive non-parsed MICR data and return 
25 parsed MICR data elements in transit routing number and check number fields. The drawee 
bank also develops a means for reporting POS Check Service transactions on the customer's 
checking account statements. 

hi addition to the above setup performed by a participating drawee bank, the third party 
also performs tasks such as arranging customer support for transactions they deny, arranging 
30 settlement vd.th the switch for POS Check Service transactions they authorize and 

reconciliation of those transactions, setting up service options supported, providing rq^orts or 

10 
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raw data for reporting, creating an ACH file on behalf of the acquiring banks, and provi-diBg 
additional services to acquiring banks, such as image archiving and collection services. 

FIG- 4 is a more detailed illustration of paper check 106, As described above, check 106 

may be any suitable personal check or even other types of checks as permitted by law. On the 
5 lower edge of check 106 is a line of information 252 conmioBly termed the MICR (magnetic 
ink character recognition) data. Included within this line are separation characters 254, 258, 
262 and 266 which separate the various pieces of information. Infonnation 256 is a sequence 
of characters that is the transit routing mmiber, also termed the ABA number. Information 
260 is a sequence of characters identifying the customer's account number, termed ttie on-us 

10 data. Information 264 is a sequence of characters identifying the serial number of the check 
As separators 254, 258, 262 and 266 are symbolic characters (also termed "nonprintable 
characters"), they are typically translated later into alphanumeric characters. When Ihe 
separators in the MICR data are later translated into alphanumeric characters, they are 
typically translated to the characters "T", "0'\ "A" and 'T)" which is referred to as the raw 

15 TOAD format. Translation occurs because a computer systems cannot understand 

nonprintable characters, and this simple substitution allows the system (or another system) to 
eventually parse the mformation. 

FIG. 5 is a flow diagram describing how a request is initiated to convert a check at the 
point of sale. At this point in tune, a customer is performing a transaction with a merchant 

20 and desires to make a purchase using a paper check for payment, in step 202 the clerk enters 
the amount of the transaction into one of the devices described in FIG. L Of course, this 
amount may also be entered by the customer or may in some instances by automatically 
entered into a cash register using scanning or other known techniques* In step 206 the 
customer presents a paper check for payment. The check is in payment for goods or services 

25 and may not be filled out. The customer may receive cash back if the POS Check Service 
transaction is keyed for an amount abov"^ '-^c purchase price. The cash back amount is 
xiniquely identified in the POS Check S e authorization message. 

hi step 310 the check is swiped through one of the devices described in FIG. 1. 

Preferably, the check contains MCR data and is swiped through a MICR device. Next, the 
30 device reads the raw MKM. data from the bottom of the check in step 3 14. This data will 
include the transit routing number, the accoimt number of the customer and the check serial 

11 
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number. The device translates the symbols into the appropriate alphanumeric charactors (raw 
TOAD format). This translation may also occm: at the acquirer. This translation occurring at 

the device or at the acquirer is not an actual parsing, it is simple substitution of famiHar 
alphanumeric characters for nonprintable separation symbols. The translation assumes no 
5 knowledge about the structure of the MICR encoded information other than recognizing which 
nonprintable symbol matches with which alphanumeric character. As mentioned earher other 
devices and readers may be used to obtain the necessary information for the paper check and 
in certain embodiments the paper check is not required but the identifying information is 
entered via a keypad or other means herein described. 

10 In an optional step, in step 322 additional customer information is entered into the 

device. This additional customer mformation may include identification such as driver's 
license number, state identification number, military identification numba:, etc. Various types 
of customer uif ormation are presented in Table 1 . This information is optional and variable 
and depends upon the individual requirements of the participating merchant, acquirers and 

15 third-party authorizing agents. 

As shown in Table 1, the processing code is used to identify fee type of POS Ch^k 
Service transaction that the merchant desire. A merchant may requ^t that a check be 
converted, be verified and converted, or be guaranteed and converted. If a merchant requests 
Conversion Only, the transaction will be approved or declined by a participating bank on 

20 which the check is drawn or by a third-party authorizing agent with minimal account 

verification processing. If the merchant chooses Verification with Conv ersion, the request 
method will be routed to a participating bank on which the check is drawn or to an authorizmg 
agent for verification of the probability that the check will be paid based on mformation 
available at the tune of the request. The merchant will then receive eifeer an ^proval or 

25 decline response. If the merchant chooses the Guarantee with Conveareion option, the request 
message will be routed to a participating bank on which fee check is drawn or to an 
authorizing agent to guarantee fee check. The merchant will feen receive eifeer an approval or 
decline response. 



Field Name 


Usage 


ID Type and 
Number 


Identifies fee fype and number of fee customer identification present at 
the point of sale. Used in fee request. This field may be repeated as 
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often as necessary, if infonnation from multiple ID types is captured at 
the point of sale. The first two positions in this field are either a valid 
state code or an ID Type such as Military ID, Courtesy Card, social 
security number, proprietary card, military base, embassy or traveling 
merchant. If the value in the first two positions is a valid state code, then 
the number following it is either a valid driver's license number or State 
ID. If the value in the fist two positions is a valid ID Type, then the 
number following it corresponds to the ID Type presented. 


Date of Birth 


Identifies a date of bkth, field length, and contents. Used in the request. 


Telephone 

Number 


Identifies a telephone number, field length, and contents. Used in the 
request. 


Response 
Source 


A one-digit response source identifier returned by a non-bank authorizer 
in all responses. Used in the response. 


Reference 
Number 


Identifies a reference number of any type, field length, and contents. 
Used in the response. 


Proprietary 

Response 

Information 


Identifies proprietary response information defined by an authorizing 
agent, field length, and contents. Used in the response. 


Receipt 
Information 


Identifies customer receipt infomiation, field length, and contents. Used 
in the response. 


Call Back 
Information 


Contains non-bank authorizer name, address, and customer service 
telephone number. The field is preferably returned by non-bank 
authorizers on declines of original requests. Used in the response. 



Table 1 



Additional Customer Data — Private 



In step 326 the request message is built using the assembled information. The message 

5 can be assembled at the merchant or at the acquirer, but is typically assembled before being 
transferred to the sendee organization. The merchant also determines which service it 
desires, i.e,. Conversion Only, Verification with Conversion or Guarantee with Conversion. 
Regarding the different methods of service, a merchant may choose Conversion Only because 
his main objective is to eliminate paper processing and he anticipates a low-risk with the item. 

10 If a merchant is concemed about the authenticity of a check and wants to verify that fiinds are 
present in the customer's checking account at the trnie of purchase, the merchant may choose 
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Verification with Conversion because there is a greater likelihood that the merchant will be 
paid. If a merchant wants guaranteed payment of the item, he may choose Guarantee wilh 
Conversion, in which case the guarantor bears the habiiity even if the check is not honored. 

The POS Check Service message may be assembled using any desired format until it 

5 reaches the host connected to the ser\dce organization, at which point it must be formatted into 
the standard message format of the service organization, and includes such information as a 
merchant temiinal identifier, a merchant identifier, a third-party identifier, the amount of cash 
b^k desired, the RAW TOAD MICR data, the transaction amount, terminal capability 
information, information sufficient for clearing and settlement, and an indication of the service 

10 desired by the merchant. A list of possible infoimation is presented in Tables 2 and 3 , Other 
data fields include: Bitmap, secondary; transmission c^te/time; Systems trace audit number; 
local transaction tkne; local transaction date; settlement date; merchant type; acquiring 
institution country code; acquiring institution ID code; retrieval reference number; card 
acceptor terminal ID; card acceptor ID code; card acceptor name/location; transaction currency 

15 code; national POS geographic data; network ID code; acquirer business ID: receiving 
institution ID code and additional trace data. 



Field Name 


Use 


Suggested Data Requirements 


Processing Code 


Identifies the type of POS 
Check Service transaction. 


Guarantee with Conversion = 

03. 

Verification with Conversion = 
04. 

Conversion Only =18. 


Transaction Amount 


Amount of transaction. 




Point of Service Entry 
Mode Code 


Identifies the method used 
to capture the MICR data. 




POS Condition Code 


Serves as an identifier, in 
conjimction with the 
Processing Code. 


The POS Condition Code for 
POS Check Service transactions 
is 52 on all original full financial 
transactions. 


Check Settlement Code 


Provided by the service 
organization in responses to 
indicate the settlement 
disposition of the 
transaction. 


Switch Settlement Code = 1 . 
ACH Settlement Code = 2. 
Field not be present if the item 
will not be settled. 


Additional Customer Data- 


May be used for any 


See Table L 
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-Private 


customer identification 
information specifically 
required by an autiiorizer. 




Additional POS Data 


A private-use field defined 
by tlie service organization 
to provide additional 

information about the point 
of sale or service. 




Other Amoimt, 
Transaction 


Should contain the c^h 
back amount firom the 
transaction, if any. 


The c^h back amount should 
not exceed the Transaction 
Amount. 


Transaction Ideritifier 


Will contain a unique 
transaction identifier 

assigned by the service 
orgaoization. 


This field wiU be sent to 
transaction recipients and 
returned to transaction 
originators. 


Receiving Institution ID 
Code 


Contain the BM ID of the 

third-party authorizer that 
the originator wants to 
receive the transaction. 


If the check is drawn on a 
participating drawee bank^ the 
service organization will route 
the transaction to that bank. 

Otherwise, the transaction will 
be sent to the designed third- 
party authorizer. 


Supporting Information 


Contains the MICR 

kifomiatioii firom the 
customer's check. 


See Tables. 



Table 2 
Request Message 



Field Name 


Data Content 


Format 


Data Type 
Identifier 


RM 


Identifies the data contents as 
unformatted MICR information. 


Data 

Length 

Identifier 


999 


Indicates the length of the MICR data 
contained in the field. 


MICR 

hafomiatio 

n 


Contains the unaltered contents of 
the MICR line, with spaces 
preserved, read from the customer's 
check by a terminal. At a minimum, 
the Transit Routing Number and 
Customer Account Number (On-us 
field) should be present. 


The unformat^ MICR data is 
preferably the same MICR line from the 
check, including spaces, except that the 
MICR symbols should be replaced as 
follows: 

The Transit symbol is replaced by the 
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Refer to UBdeistanding and Design 
Checks, ANSI Standard X9/TG-2 
(1990). 



letter "T" in either upper or lower case. 

The Ob-US symbol is replaced hy the 
letter in either upper or lower case. 
The Dash symbol is replaced by the 
letter *T)" in either upper or lower case. 



Table 3 
MICR Information 



FIGS. 6A, 6B and 6C are a flow dia^am describing the authorization and clearing of a 
5 transaction. Once a complete POS Check Service request message has been received by the 
host, and has been reformatted, the host sends the request message online to the service 
organization (switch) for central processing and routing to an authorizing endpoint. In step 
402 the host reformats the message and sends it to the service organization. This reformatting 
is done in order to be in compliance wifli the switch interf^e sp^ifications. 

10 In step 406 the switch performs exclusion checking on the request. As part of the switch 

processing, a limited ABA exclusion verification is applied. In one embodiment, an ABA 
exclusion table is used. If the authorization request contains an ABA number (the transit 

routing number) that is included in the ABA exchision table, the switch will immediately 
return a decline response to the host with an appropriate response code. Included in the 

15 exclusion table are ABA numbers that identify government checks (U.S. Treasury^ and Federal 
Reserve), traveler's checks, or an instrument with a non-check ABA number. ABA nimibers 
are known to one of skill in the art and the table may be edited to exclude any typ^ of checks 
based upon an ABA number. Preferably, the switch or its agent should be able to add or 
delete ABA numbers from the repository of online exclusion and offline translation data. 

20 These data repositories should be updated not less than daily. 

Preferably, the ABA number is extr^ted from the raw TOAD format MICR data 
without the need for pairing the data. Because it is known that ABA number is bounded by 
the tag and is nine digits long, it is simple to extract the number for exclusion checking 
and later routing. Essentially, the svntch "looks" at the ABA number but does not perform 

25 parsing (although it is possible for parsing to occur here). 
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Preferably, the service organization also edits the transaction request to ensmre valid data 
formats, and to insure the transaction complies with the business rales governing the service. 
Other checks such as duplicate checking are performed. The switch performs duplicate 
checking on originals to ensure merchants and acquirers do not submit identical requests. If 
5 the transaction passes these edits and checks, the service organization forwards the trax^action 
to either a participating bank on which the check is drawn or to a third-party authorizing agent. 

Based upon a list of participating banks, in step 410 the switch attempts to match the 
transit routing number with that of a participating drawee bank. If there is a match, then in 
step 414 the switch determines whether the service requested of the merchant matx:hes a 

10 service provided by the drawee bank. If so, tfaen in step 41 8 the settlement code in the request 
message is set to a "1" (or other symbol) to signify that settlement will eventually occur 
through the switch. The switch also generates a unique transaction identhSer for the current 
transaction in step 430. Preferably, ail transactions have an audit trail which ties together 
related transactions in a transaction set — ^thus, future reversals, voids, etc. can all be related to 

15 the original transaction. The unique transaction identifier may be used for this purpose. Next, 
this request message is sent to the participating drawee bank in step 434. If the switch 
determines the drawee is unavailable, a response for "Service Not Available" is sent to the 
m^chant's acquirer. 

In step 438, the bank handles the request as per the service requested by the merchant. 

20 The raw TOAD MICR data is first parsed as explained below. If Conversion Only is 

requested, then the bank may merely check to see that a valid account does exist at the bank, 
that the account has not been closed, and that the accoimt is not fraudulent. (IfinvaUd, a 'T)o 
not Honor" response is returned to the merchant's acquirer.) The bank is not obligated to 
perform further checking or verification. When Verification with Conversion is requested, 

25 then in step 454 the bank not only verifies that the account is valid, but also that the amount of 
funds in the accoiint is adequate for the transaction. In a preferred embodiment, a bank will 
also place a hold upon the account for the transaction amount in this step. If Guarantee with 
Conversion is desired, then in step 462 the bank will place a hold on the account for the 
amount of the transaction and will guarantee that the amount will be paid. In other words, the 

30 bank must pay the amount regardless of the account balance. 
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Next, the bank generates a response message and returns it to the service organization, 
TMs response message contains a variety of information concerning the transaction; an 

example response message is shown in Table 4. Included within the response message is a 
response code generally indicating whether the request is approved. Examples of response 
5 codes are shown in Table 5. Table 5 shows the business reason for the response, response 
code, whether the response is approved or declined, and the responding endpoint ehgible to 
use each of the codes. Once switch 122 receives the response message, it deteraiines if there 
is an approval in step 470. 



Field Name 


Data 


Format 


Response Code 


Contains a Response 
Code valid for POS 
Check Service 
transactions as shown 
in Table 5. 




Additional Data, 
Private 


No data is required in 
this field. 


Any <Ma that a check request respondent 

chooses to include in the message should be 
formatted as shown m Table 1 . 


Support 
Mbraiation 

Field Identifier 


This field contains: 

$V 


The POS Check Service field identifier ^pears 
in the first two types of the field, as shown. 


Trarsit Routing 
Number 


The drawee baok's 

Transit Routing 
Number (ABA 
Number). 


xne Jri-Zo v^neciv oervioc lit/iu- iudj.uu.c>i a|/pwai*3 
in the first two bytes of the field, as sho^Ti. 
The Transit Routing Number has a fixed length 
of 9 numeric characters and may be formatted 
as follows: AB999dddd, where AB identifies 
the sub-field, 999 the length of the data, and 
dddd, the actual data contents. 


Customer 
Account Number 


The customer deposit 
account number 


The customer deposit account number should 
be present, a maximum of 19 characters and 
preferably formatted as follows: 
AN999dddd, wh^e AN identifies the sub- 
field, 999 the length of the data, and ddddl, tiie 
actual data contents. 


Check Serial 
Number 


The check serial 
number of the check 
being converted. 


The check serial number should be present, a 
maximum of 15 charactei^, and preferably 

fomiatted as follows: CK999ddd4 where CK 
identifies the sub-field, 999 the length of the 
data, and dddd, the actual data content. Any of 
the alpha characters sent in this field in the 
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request message Cf\ ''d'') should be 
stripped out when the field is returned. 

Table 4 
Response Message Fields 



Business Condition 


Response 
Code 


Approve/ 
Decline 


Service 
Organizatioii 


Non-bank 
Autiiorizer 


Participating 
Drawee Bank 


Unconditional 
Approval 


00 


A 




Y 


Y 


Invalid merchant ID 


03 


D 




Y 




Do not honor 


05 


D 




Y 


Y 


Invalid account 


14 


D 




Y 


Y 


No such issuer 


15 


D 


Y 






NSF 


51 


D 




Y 


Y 


Transaction not 
permitted 


57 


D 


Y 


Y 


Y 


Too much cash (over 
merchant or bank 
limit) 


61 


D 




Y 


Y 


Exceeds withdrawal 
frequency limit 


65 


D 




Y 


"XT' 

Y 


UnsoHcited reversal 


/u 


U 


Y 

X 






Reversal received 
form denied request 


80 


D 


Y 






fesuer unavailable 


91 


D 


Y 






Routing error 


92 


D 


Y 


Y 


Y 


Duplicate 

Transaction 


94 


D 


Y 






System error 


96 


D 




Y 


Y 


Approval, keep first 


TO 


A 




Y 
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check 












Check IS OK, but 
check cannot be 
converted 


i 1 


jj 




V 




invalid Tramit 
Routing Number 


T2 


D 


Y 


Y 




Amount greater than 
established service 
limit 


T3 


D 




Y 




Unpaid items, failed 
negative file check 


14 


U 




Y 




Duplicate check 
nimiber 


T5 


D 




Y 


Y 




T6 


D 




Y 


Y 


Too many checks 
(over merchant or 
bank limit) 


T7 


D 




Y 


Y 



Table 5 



Response Codes 



Returning for a moment to the ''NO" branches of stq)S 410 and 414, if the transit routing 
5 does not match the table of participating banks, or the service requested by the merchant does 
not match the service provided by the participatmg bank, then in step 484 the settlement code 

in the request message is set to a "'T (or other suitable symbol) to signify that settlement will 
be through ACH because a third-party authorizing agent is used. The following steps describe 
actions occurring when the authorization request is sent to the third-party authorizing agent 

10 126 m step 485. In some ways, the request is handled in a similar fashion as the participatmg 
drawee bank handles the request as described in FIG. 6B. Because the third party, however, 
does not h^ve control over the customer's accoimt, it must use other means to provide 
verification and guarantee. In st&p 486 the request is handled as per the service request. The 
raw TOAD MICR data is first paired as explained below. If the request is for Conversion 

15 Only, then in step 488 the third party, at a minimum, verifies that the check is ehgible to be 
converted into an ACH item. 
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If the request is for Verification with Conversion, then in step 490 the third party, at a 
minimum^ performs velocity checks, searches their database of retomed checks, verifi^ 
against risk models, etc., to determine the probabihty that the POS Check Service trans^on 
amonnt will be paid by the customer's bank. If the request is for Guarantee with Conversion, 
5 then in step 492 the third party performs velocity and database checks and will underwrite the 
amount of the request, guaranteeing payment even if the item is retuxned. Finally, in step 493 
the third party generates a response message in much the same way as in step 466 and sends 
the response to the service organization. 

Returning to step 470 of FIG. 6B, once the response message has been r^eived by the 
10 service organization, it determines whether the transaction been approved. More 

specifically, switch 122 processes response messages as shown in Table 6. If the transaction 

has been approved, the message is sent to the acquirer or merchant host who then reformats 

the message into the protocol used with the merchant, and sends the response message back to 
the merchant. If the transaction was not approved, the switch first removes the settlement 
15 code in step 478, indicating that the item is not settled, before sending the response message 
back to the acquirer or merchant. Once the response message is received by the merchant, tiae 
transaction is then completed at the point of sale as described below. 



Field Name 


Contents 


Switch Processing 


Response 
Code 


The Response Code 
should be valid for POS 

Check Service 

transactions and vai: 
for the sending party, as 
shown in Table 5. 


If the Respoiise Code is not vahd, the switch will 
reject the transaction and will send a "decline" 
response to the originator of the response, with 
Response Code 91. 


Check 

Settlement 

Code 


Switch will add under 
certain conditions. 


If the response message carries an approval 
Response Code and passes all Switch edits, the 
Switch will add this field, indicating the 
settlement type for the transaction. A value of 1 
means that the Switch will settle the transaction. 
A value of 2 means that the transaction will settle 
through the Automated Clearing House (ACH). 


Transaction 
Identifier 


Contains the 
Transaction Identifier. 


The Switch will restore the Transaction Identifier, 
if it is not returned in the response message. 


Supporting 
Information 


Contains the Transit 
Routing Number, the 


The Switch will edit the field for presence, correct 
formatting and required data. If the field is not 
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Customer Account 
Number, and the Check 
Serial Number, 



present, the Switch will reject the transaction. If 

the transaction is approved and if the required 
Transit Routing Number, Customer Accoimt 
Number, and Check Serial number are not 
present, or the formatting of the fileld is incorrect, 
the Switch will rej ect the transaction. If the 
transaction is approved and if the Transit Routing 
number does not match the Transit Routing 
Number submitted on the original request, the 
Switch will reject the transaction. 
If the transaction is declined, the Switch will not 
edit for the presence of this field 



Table 6 



Smtch Processing of Response Messages 



As mentioned above in steps 438 and 486, parsing is first performed on the raw TOAD 
MICR data before the service request is handled. Although it is possible to perform parsing at 

5 the MICR reader, it is preferable to parse at the drawee bank or a third party authorizer. 
Because there are many different MICR readers on the market of varying quality and 
implementation, pairing MICR information at the MICR Reader level is prone to numerous 
errors. These errors can result in increased problems authorizing transactions and lengthen 
transaction times, which leads to consumer and merchant dissatisfaction. This embodiment of 

10 the present invention chooses to move the parsing ofMICR data to the authorizer of the 
transaction. 

Parsing implies knowing the rales for extracting the ABA number, the account number 
and the check serial number from the MICR line. There are potentially thousands of rules for 
account number structure and various ways for encoding the check serial number in the MICR 

15 line. To fully parse the MICR line requires building a table of these rules or buying such a 
table from a provider. Third party authorizers have years of experience in building databases 
of proprietary parsing rules, likewise, drawee institutions are in the best position to detemiine 
the account information from the MICR line as they are the account holder. Moving pairing 
from the point-of-sale temiinal to an authorizer avoids unnecessary service errors up front and 

20 places parsing at a point in the transaction flow which ensures the greatest success of 
successfully parsing the MICR information. This leads to an improved consumer and 
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merchant experieiace at the point of sale and delivers financial benefits because it increases the 
number of successful check conversion transactions. 

Preferably, parsing is performed at a drawee bank or at a third party authorizer using 

known techniques. The drawee bank or authorizer first receives the incoming request, extracts 
5 the MICR information and processes it against their existing database of MICR line stmctiBres. 
Typically, the bank or authorizer uses proprietary tables and databases of known line 
stmctures to extract out the routing and transit information, account number and check serial 
number. One of skill in the art familiar v^th these parsing techniques would be able to extract 
the necessary information from the MICR line. 

10 FIG. 7 is a flow diagram describing the completion of a transaction at the point of sale. 

At this point, the merchant has received a response message from the acquirer and will 
complete the transaction with the customer. B^ed upon the response code in the response 
message, the merchant is advised as to whefh^ the transaction has been approved or declined. 
Preferably, based upon this information, the merchant will either accept or reject the 

15 customer's check. Even if the transaction has been declined, however, the merchant may still 
decide to accept the customer's paper check like a nomial check transaction, i.e., not 
converting the check into a electronic transaction. 

Assuming that the transaction is approved, the merchant then stamps the customer's 
check "VOID" and returns the check to fiie customer. The POS Check Service uses a 
20 Consiimer-As-Keeper model, and therefore, the merchant does not keep the paper check, but 
returns it to the customer. In step 510 the merchant generates a receipt for the customer; one 
such example of a receipt is shown in FIG. 8. Finally, in step 514 the customer signs a copy of 
the transaction receipt which is retained by the merchant. This signed receipt proves that the 
customer has authorized the paper check to be converted into an electronic transaction. 

25 FIG. 9 is a flow diagram describing the settlement of transactions. At the end of each 

day, the acquirer is aware of all trai^actions from its participatmg merchants. Typically, the 
acquirer then reconciles the transactions for all merchants in step 550 and notifies merchants 
when settlement funding will occur. Also, an acquirer may choose to pre-fimd a merchant for 
a particular transaction depending upon the type of the transaction and/or the type of merchant. 

30 The merchant will receive such settlement information informing the merchant of how to 
expect payment. For example, in step 554 the merchant receives ioformation uniquely 
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identifying any checks written to the merchant that have been converted into an electronic 
transaction. 

ha step 558 settlement is performed. As is known in the art, typically at the end of each 
business day at 10:00 p.m., the service organization looks at the difference between debits and 
credits and calculates net settlement for all participants. A federal wire transaction is initiated 
to then move money between settlement accounts. Eventually, an acquirer will distribute 
payment to each of its merchants. As mentioned earher, the settlement code can be used by 
the acquirer and merchant to understand where payment will be coming from. For example, if 
a batch of checks is converted using the present invention and are identified as being handled 
by an ACH transaction, the merchant will then realize that it may take a day longer for 
settlement to occur. 

As mentioned above, the means of settlement is determined at the time of authorization 
based on how the transaction is routed for authorization. POS Check Service transactions 
authorized by a participating drawee bank are settled throu^ the service organization. POS 
Check Service transactions authorized by a third-party authoiizmg agent are settled through 
the ACH network. Various embodimente for settlement step 558 are presented below. Switch 
122 is arranged to provide any of a variety of activity reports detailing settlement that are 
tailored for merchants, acquirers, drawee banks, etc. These reports include all POS Check 
Service transactions, both those settled through the Switch, and those settled through the 
ACH. An example of an activity report for a participating drawee bank is shown in FIG. 18. 

SETTLEMENT EMBODIMENTS 

FIG. 10 illustrates the settlement process for transactions settled via the service 
organization or switch. The flow shows one transaction, but represents the deUvery of batches 

of POS Check Service transactions to multiple acquirers/processors and participating drawee 
banks. Settlement files are exchanged daily for approved POS Check Service transactions that 
the switch has exchanged v/ith participatmg drawee banks. If the same BM is used for activity 
other than POS Check Service transaction processing, the POS Check Service settlement total 
will be combined with the settlement total for other activity processed by the switch. 

For POS Check Service transactions authorized by participating banks at the end of the 
day, numerous tasks are performed. The switch provides settlement mformation to acquirers 
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and p.articipatiiig drawee banks. The switch, also sends rav/ data and reports to acquirers and 
participating drawee banks. Acquirers reconciie the credit amount to their merchants' 
accounts and drawee banks apply debits and credits to their customer's checking accx)unts. 

FIG, 1 1 illustrates the settlement process for POS Check Service transactions via the 
5 ACH. (Authorization already having occurred via the system shcmn in FIG, 1, for example.) 
For settlement of transactions drawn on non-participating banks, the ACH enables the routing 
of transactions to the specific acquirer or RDFI (Receiving Depository Financial Institution). 
In this context, an RDFI is a financial institution that receives a POS Check Service 
transaction and debits it firom the customer's checking account POS Check Service 
10 transactions exchanged by the switch and third-party authorizing agents are settled by the 
ACH, All post-settlement items relating to the transactions are processed according to the 
ACH rules published by NACHA. 

For POS Check Service j:ansactions authorized by a third party, certain tasks occur at 

the end of the day. First, the third party sends its data to the ODFI (Originating Depository 

15 Financial Institution). Next, the ODFI processes all On-Us trai^actions and forwards all non- 
On-Us transactions to the ACH. The ACH then fomards all debits to the RDFL The ACH 
forwards all credits to the acquirer. The RDFI will forward the debit to the customer's 
checking account and the acquirer sends the credit amount to its POS merchant. 

FIG. 1 ^ diustrates a settlement flow for a participating drawee bank. Shown is the flow 
20 for a request message, a response message, and settlement when the check to be converted is 
drawn upon a participating bank 124, 

FIG. 13 illustrates a settlement flow through the ACH for a non-participati: Irawee 
bank. In this situation, the switch 122 has purchased a third-pait>^ authorizing agent and 
performs the ACH processing in-house. Thus, the switch not only handles authorization of fee 
25 transaction, but also initiates the request to the ACH and ODFI for settlement between the 
acquirer 120 and draw^ bank 124. 

FIG. 14 illustrates an alternative flow for a non-participating drawee bani:. In this 
example, the converted check is drawn on a non-participating drawee bank, thus causing the 
third party to perform authorization. In this situation, though, the request for ACH settlement 
30 comes from the switch and not from the third party. 
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AUTHORIZATION EMBODIMENTS 

FIG. 1 5 illv^ates m example of an authorization flow in which the acquirer aiKl the 
drawee bank are the same. In this example, the merchant acquire: bank 120 is the same as the 
5 drawee bank 124 on which the customer's check 106 is to be drawn. Service request for 
Conversion Only 602 and Guarantee with Conversion 606 are directed to the drawee bank 
wloich supports them, while a request for Verification with Conversion 604 is directed to a 
third pdxty 126 approved by the acquirer because the drawee bank does not support this 
service. 

10 FIG. 16 is an example of an authorization flow in which the acquiring bank is not the 

same as the drawee bank. In this example, the merchant's bank 120 is different from drawee 
bank 124 upon which the customer's check 106 is to be drawn. Service request for 
Conversion Only and Verification with Conversion, 602 and 604, are directed to and 
authorized by drawee bank 124 because it supports these services. The drawee bank does not 
15 support Guarantee with Conversion, thus, a request for this service is routed to and authorized 
by third party 126. 

FIG. 17 is an example of an authorization flow in which the customer's check 106 is to 
be drawn on a bank which does not participate in the PCS Check Service. M this example, 
check 106 is drawn on the fictitious Bank of Jack which is different from the acquiring bank 
20 120. Because the Bank of Jack does not participate in tiie POS Check Service, all service 
requests 602-606 are routed to and authorized by third party 126. 

FIG. 18 is an example of an activity report for a participating drawee bank as referenced 
above. 

POINT OF inANSACTION ALTERNATTV^E EMBODIMENTS 

25 

In any one of many alternative embodiments, the POS Check Service can be adapted as 
explained below to fimction not only as a "point-of-sale" check service, but also as a "point- 
of-tiransaction" check service. The service described above is termed a "point-of-sale" service 
in that the check is being surrendored to the merchant by the customer at the point of sale. 
30 There are, however, other situations in which a sale is being made, and a customer would wish 
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to pay by check, yet the customer is not presenting a paper check in person. These situations 
can be temied a ''point of transactiotf ' and include situations in which a customer mails in a 
check or in which a customer uses a check over the Internet. 



5 hi the first scenario, the customer desires to purchase a product or service from a 

merchant but instead of appearing in person and presenting the check (as shown in FIG. 1), the 
customer may simply mail the check to the merchant along with an EFT authorization form as 
part of the order form. The customer is either aware of the amount of the product or service, 
or indicates somehow in the correspondence how much the check should be written for. The 

10 merchant v/ould then process the check as has been described above in FIG. 5 . In other words, 
the merchant swipes the check through a reader, enters the amount of the traBsaction and sends 
the information off. If other identifying information is required of the customer the merchant 
may request this ahead of time, the customer may present this information in the 
correspondence, the merchant may keep this information on file for the customer, or the 

15 merchant may telephone or write back to the customer in order to get the information, etc. in 
any case, any further customer identifying infomiation needed by the merchant to complete flie 
transaction can be readily obtained from the customer even though the customer is not present 
in person. 

20 The customer may even complete a transaction using a check over the hitemet. Once a 

customer has deteraiined a product or service to buy on the Internet, a series of questions or 
screens on the web site directs the customer to enter the appropriate information from the 
paper check. In this situation, the customer would view one of their own paper checks in front 
of the computer and type in the MICR line information as requested by the web site. In other 

25 words, flie customer at home is essentially parsing the MICR line themselves and providing 
the ABA and accoimt number to the web site. The web site may also ask for any other needed 
identifying information of the customer, including the amoimt of the transaction, etc. Thus, in 
these two situations a point-of-transaction check service is provided in which a customer 
makes a purchase using a check without being present in person at the merchant's location of 

30 business. 

In another scenario, a person may wish to make a deposit to their checking account at 
an ATM using a check from someone else or perhaps their own check. Typically, the check is 
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a payroll check to the customer. In fact, the customer may even make a deposit to their own 
account using one of their own checks. In this situation, the customer inserts the paper check 

at the ATM where it is read internally hy any of the devices described in FIG. 1 or the 
customer may also swipe the paper check through a suitable reader on the outside of the ATM. 

5 The check may be returned to the consumer or may be held intemally, but the paper check is 
not needed as a negotiable instrument as described above. Once the check has been inserted, 
the customer keys in the amount to be deposited or the deposit amount may be read from the 
check iteelf using OCR technology. Once the check has been inserted (or swiped) and the 
amoimt to be deposited received, processing continues as described in FIG, 5. In this situation 

10 the customer enters their own account number to be credited and it is this account at the 
customer's banlc which is treated as if it were the merchant's account as has been described 
above. Thus, a customer may deposit a check to their own account using the techniques 
described above. In fact, any person can present a check in this fashion at an ATM and 
indicate that it be deposited to any vahd account simply be keying in the ^count information. 

15 The check to be deposited need not be directed toward the account of the person inserting the 
check in the ATM, 

In a similar situation, a customer may wish to put money into a brokerage account 
using a paper check. In this situation the customer tendex^ a paper check to their broker who 

20 behaves as a merchant may and processes the check as described being in FIG, 5. The 

recipient of the amount to be deposited would not be the brokerage fimi itself hi this case, but 
would be a brokerage account of the customer located with the particular brokerage firm. 

In either of the above scenarios, ATM deposit or brokerage account deposit, the entity 
25 accepting the deposit (like the merchant accepting payment described above) will initiate an 
electronic request to debit the check writer's account. The debit to the check writer's account 
will follow the same processing as it will under the point of sale scenario. The advantage is 
that the bank or brokerage can simply initiate an online debit request instead of moving the 
paper through the system. This speeds up receipt of the funds and also helps ensure payment 
30 on the check that was deposited. Thus, in the above two scenarios a customer is able to use a 
point-of-transaction check service in order to make a deposit originating with a paper check. 
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SYSTEM HARDWARE EMBODIMENT 

In one embodiment of the inventioB, a particular inj&astructure provides the data 

processing systems, networks, and operations to support and deliver authorization, clearing 
and settlement services for the POS Check Service. 

5 FIG, 19 illustrates a telecommunications network 800 suitable for implemmting an 

embodiment of the present invention. The present invention may make use of any suitable 
teleconimiHiications network and may involve different hardware, different software and/or 
different protocols then those discussed below. The below-described network is a preferred 
embodhnent Network 800 is a global telecommunications network that supports purchase 
10 and cash transactions using any bankcard, travel and entertainment cards, and other private 
label and proprietary cards. The network also supports ATM transactions for other networks, 
transactions using paper checks, transactions using smart cards and transactions using other 
financial instruments. 

These transactioi^ are processed through the network's authorization, clearing and 
15 settlement services. Authorization is when an issui^ approves or decUnes a sales transaction 
before a purchase is finalized or cash is dispersed. Clearing is when a transaction is delivered 
from an acquirer to an issuer for posting to the customer's account. Settiement is the process 
of calculating and determining the net financial position of each member for all transactions 
that are cleared. The actual exchange of hmds is a separate process. 

20 Transactions can be authorized, cleared and settled as either a dual message or a single 

message transaction. A dual message transaction is sent twice — tiie first time with only 

information needed for an authorization decision, an again later with additional information 

for clearing and settlement. A single message transaction is sent once for authorization and 
contains clearing and settlement information as well. Typically, authorization and clearing all 
25 occur online. 

The main components of telecommunications network 800 are mterchange centers 802, 
access points 804, 806 and processmg centers 808 and 810. Other entities such as drawee 
banks and third-party authorizing agents may also connect to the netm^ork through an access 
point. An niterchange center is a data processing center that may be located anywhere in the 
30 world. In one embodiment, there are two in the United States and one each m the United 
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Kingdom and in Japan, Each interchange center houses the computer system that performs the 

network transaction processing. The interchange center serves as the control point for the 
telecommunication facilities of the network, which comprise hi^ speed leased lines or 
satelhte coimections based on IBM SNA protocol. Preferable, lines 820 and 822 that connect 
5 an interchange center to remote entities use dedicated high-bandwidth telephone circuits or 
satellite connections based on the IBM SNA-LUO communication protocol. Messages are sent 
over these lines using any suitable implementation of the ISO 8583 standard. 

An access point 804 or 806 is typically a small computer system located at a processing 
center that interfaces between the center's host computer and the interchange center. The 
10 access point facihtates the transmission of messages and fil^ between the host and the 

interchange center supportmg the aufliorization, clearing and settlement of transaction. Links 
826 and 828 are typically local links within a center and lise a proprietary message foxmat as 
prefer by the center. 

A data processing center (such as is located within an acquirer, issuer, or other entity) 
15 houses processing systems that support merchant and business locations and maintains 

customer data and billing systems. Preferably, each processing center is linked to one or two 
interchange centers. Processors are connected to the closest interchange, and if the network 

experiences interruptions, the network automatically routes transactions to a secondary 
interchange center. Each interchange center is also linked to all of the other interchange 

20 centers. This linking enables processing centers to communicate with each other through one 
or more interchange centers. Also, processing centers can access the networks of other 
programs through the interchange center. Further, the network ensures that all hnks have 
multiple backups. The connection from one point of the network to another is not usually a 
fixed hnk; instead, the interchange center chooses the best possible path at the tune of any 

25 given transmission. Rerouting around any faulty link occurs automatically. 

FIG. 20 illustrates systems 840 housed within an interchange center to provide online 
and ofiEUne transaction processing. For a dual message transaction, authorization system 842 
provides authorization. System 842 supports online and offline functions, and its file includes 
intemal systems tables, a customer database and a merchant central file. The online functions 

30 of system 842 support dual message authorization processing. This processing involves 

routing, cardholder and card verification and stand-in processing, and other functions such as 
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file maintenance. Offline fimctions including reporting, billing, and generatdBg recovery 
bulletins. Reporting iacludes authorization reports, exceptioa file and advice file reports, POS 
reports and billing reports. A bridge firom system 842 to system 846 makes it possible for 
members using system 842 to communicate with members using system 846 and access the 
5 SMS gateways to outside networks. 

Clearing and settlement system 844 clears and settles previously authorized dual 
message transactions. Operating six days a week on a global basis, system 844 collects 
financial and non-financial information and distributes reports between members. It also 
calculates fees, charges and settlement totak and produces reports to help with reconciliation. 
10 A bridge forms an interchange between system 844 processing centers and system 846 
processing centers. 

Single message system 846 processes fiill financial transactions. System 846 can also 
process dual message authorization and clearing transactions, and communicates with system 
842 using a bridge and accesses outside networks as require. System 846 processes Visa, 

15 Plus, Interlink and other card tmasactions. The SMS files comprise intemal system tabl^ fliat 
control system access and processing, and the cardholder database, which contams files of 
cardholder data used for PIN verification and stand-in processing authorization. System 846 
performs online, real-time cardholder transaction processing and exception processing for 
authorization as well as Ml financial transactions. System 846 also accumulates 

20 reconcihation and settlement totals. System 846 offline fimctions process settlement and 

funds transfer requests and provide settlement and activities reporting. Settlement service 848 
consolidates the settlement fimctions of system 844 and 846, includmg Interlmk, into a single 
service for all products and services. Cleaiing continues to be performed separately by system 
844 and system 846. 

25 FIG, 21 illustrates another view of the components of telecommunications network 800. 

Integrated payment system 850 is the primary system for processing all online authorization 
and financial request transactions. System 850 reports both dual message and single message 
processing. In both cases, settlement occurs separately. The three main software components 
are the common interface fiinction 852, authorization system 842 and smgle message system 

30 846. 



31 

BNSDOCiD: <WO 0215039A2_I_> 



wo 02/15039 



PCT/USO 1/25531 



Common interface fimction 852 determines the processing required for each message 
received at an interchange center. It chooses the appropriate routing, based on the source of 

the message (system 842, 844 or 846), the tj^e of processing request and the processing 
network.. This component performs initial message editing, and, when necessary, parses the 
5 message and ensures that the content compUes with basic message construction rules. 
Function 852 routes messages to their system 842 or system 846 destinations, 

FIG. 22 illustrates in more detail a suitable hardware embodiment 100' for the POS 
Check Ser\dce. Included within the switch, acquirer drawee bank and third party are 
main£:ame computers 870-874 for performing processes. Access point computers 876-882 

10 facilitate communication from an entity to switch 122, High bandwidth circuits 884-887 
provide for online, real-time communication between the entities. Link 888 from the 
merchant to the acquirer is any suitable electronic transmission line such as a dial-up or l^ed 
telephone line. Data link 890, and in general, data links between access point computers and 
the host computer of an entity may use any suitable proprietary message format that the mtity 

15 desires. As mentioned earlier, the format for messages between the switch and the acc^s 
points use a suitable implementation of ISO 8583. 

Merchant 104 may choose to communicate directly from its terminal using a proprietary 

message format over link 888 to its acquirer or may wish to install an access point 876 which 
then communicates to switch 122 using the protocol of the network. Mainframe 872 fransiates 
20 the message format used in link 888 into the network protocol for comm-anication with the 
switch. Preferably, the mainframe within the switch, the access points and linlcs 884-887 are 
all redundant so there is no single point of failure. In an alternative embodiment, merchant 
104 may communicate with its acquirer over an Intemet link. Additionally a direct exchange 
protocol using the Intemet may also be used for commmiication among the various entities, 

25 FIGS. 23 A and 23B illustrate a computer system 900 suitable for implementing 

embodiments of the present invention. FIG. 23 A shows one possible physical form of the 
computer system. Of course, the computer system may have many physical forms ranging 
from an integrated circuit, a printed circuit board and a small handheld device up to a huge 
super computer. Computer system 900 includes a monitor 902, a display 904, a housing 906, 

30 a disk drive 908, a keyboard 910 and a mouse 912. Disk 914 is a computer-readable medium 
used to transfer data to and from computer system 900. 
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FIG. 23B is an example of a block diagram for computer system 900. Attached to 
system bus 920 are a wide variety of subsystems, Processor(s) 922 (also referred to as central 
processing units, or CPUs) are coupled to storage devices including memory 924, Memory 
924 includes random access memory (RAM) and read-only memory (ROM). As is well 
5 known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and 
RAM is used typically to trai^fer data and instructions in a bi-directional manner. Both of 
these types of memories may include any suitable of the computer-readable media described 
below. A fixed disk 926 is also coupled bi-directionally to CPU 922; it provides additional 
data storage capacit>^ and may also include any of the computer-readable media described 
10 below. Fixed disk 926 may be used to store programs, data and the like and is typically a 

secondary storage medium (such as a hard disk) that is slower than primary storage. It will be 
appreciated that the information retained within fixed disk 926, may, in appropriate cases, be 
incorporated in standard fashion as vktual memory in memory 924. Removable disk 914 may 
take the fomi of any of the computer-readable media described below. 

15 CPU 922 is also coupled to a variety of input/output devices such as display 904, 

keyboard 910, mouse 912 and speakers 930. In general, an mput/output device may be any of: 
video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer 
card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting 

recognizers, biometrics readers, or other computers. CPU 922 optionally may be coupled to 
20 another computer or telecommunications network using network interface 940. With such a 
network interface, it is contemplated that the CPU might receive infomation from the 
network, or might output information to the netvvork in the course of performing the above- 
described method steps. Furthermore, method embodiments of the present invention may 
execute solely upon CPU 922 or may execute over a network such as the Mtemet in 
25 conjunction with a remote CPU that shares a portion of the processing. 

In addition, embodiments of the present invention further relate to computer storage 
products with a computer-readable medium that ha\ e computer code thereon for perfomiing 
various computer-implemented operations. The media and computer code may be those 
specially designed and constructed for the purposes of the present invention, or they may be of 
30 the kind well known and available to those having skill in the computer software arts. 

Examples of computer-readable media include, but are not limited to: magnetic media such as 
hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic 
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devices; Biagneto-optical media such as floptical disks; and hardware devices that are specially 
configured to store and execute program code, such as application-specific integrated circuits 

(ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of 
computer code include machine code, such as produced by a compiler, and files containing 
5 higher level code that are executed by a computer using an inteipreter. 

Although the foregoing invention has been described in some detail for purposes of 
clarity of understanding, it will be apparent that certain changes and modifications may be 
practiced within the scope of the appended claims. For instance, the check and customer 
inforaiation may be entered at the point of sale using a scaimer, OCR equipment, biometrics 

10 readers, keypads, voice recognition, etc., in lieu of a MICR device. Also, the account 
infomiation may be represented on the check in many different fomis and using different 
characters. Other services may be performed by a drawee bajak or third party in addition to the 
three services described above. The telecommunications network used to perform online, real- 
time authorization may utihze any suitable hardware and soJftware protocol The hitemet may 

15 be used to route transaction data, arid wireless communication between entities is also 

contemplated. For example, a customer may use a wireless device to enter check infomiation 
to have the transaction authorized at the customer's location. Therefore, the described 
embodiments should be taken as illustrative and not restrictive, and the mvention should not 
be hmited to the details given herem but should be defined by the followmg claims and their 

20 full scope of equivalents. 
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CLAIMS 

We Claim: 

1 . A point-of-sale (POS) check service system comprising: 

device means for receiving checking account information from a paper check of a 
customer, and for receiving an amoimt concerning a sale to said customer, said checking 
account information and said amount being coUectively transaction information, said 

paper check not being used as a negotiable instrument aad being retumed to said 
customer; 

a host computer arranged to receive said transaction information from said device 
means and to forward it into said POS check service system; 

a switch compute arranged to receive said transaction information from said host 
computer and to further route said transaction information; 

a drawee bank which receives said transaction infomiation from said switch 
computer; and 

a drawee computer of said drawee bank that receive said transaction information 
and is arranged to perform conversion, verification or guarantee based upon said 
transaction information, said drawee compute fiirther arranged to return a response 
message to said host computer mdicating the result of said conversion, verification or 
guarantee. 

2, A POS check service system as recited in claim 1 further comprising: 

a telecomimmications network used for coimmmications between s.aid host 
computer, said switch computer and said drawee computer that pro^ddes online, real-time 
communications between said computers. 
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3. A POS check service system as recited in claim 1 wherein said device means 
includes a magnetic ink character recognition (MICR) device ttirougji which said paper 
check is swiped and a merchant point-of-sale terminal iato which said amount may be 
entered. 

4. A POS check service system as recited in claim 1 wherein said drawee computer 
is further arranged to perform conversion only, conversion with verification or conversion 
with guarantee based upon said transaction information. 

5. A POS check semce system as recited in claim 1 wherein s.aid drawee computer 

is further arranged to receive said checking accoimt information in the form of raw MICR 
data and to parse said checking account information to obtain a transit routing number 
and an account number of the customer, whereby parsing occurs reliably at a drawee bank 
and not at said device means. 

6. A POS check service system as recited in claim 1 further comprising: 

a service request message delivered to said switch computer which includes said 
transaction information and an indication of whether conversion only, conversion with 
verification or conversion with guarantee is desired 

7. A POS check service system as recited in claim 6 wherein said service request 
message includes a settlement code indicating how smlement will occur, thereby 
accommodating any customer bank and any type of service request. 
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8. A POS check service system as recited in claim 6 wherein said service reqn^t 
message includes a unique transaction identifier that ties together related transactions in a 
transaction set; 

9. A point-of-transaction check service system comprising: 

device means for receiving checking account information from a paper check of 
an individual and for receiving an amount representing a monetar>^ fransaction which is to 
be deposited into a depositing accoiint, said checking account information, said amount 
and a depositing account being collectively transaction information, said paper check not 
being used as a negotiable instrument; 

a host computer arranged to receive said transaction information from said device 
means and to forv^ard it into said point-of-transaction check service system; 

a switch computer arranged to receive said transaction information from said host 
computer and to further route said transaction information; 

a drawee bank which receives said transaction information from said switch 

computer; and 

a drawee computer of said drawee bank that receives said transaction information 
and is arranged to perform conversion, verification or guarantee based upon said 

transaction infomiation, said drawee computer further arranged to retum a response 
message to said host computer indicating the result of said conversion, verification or 
guarantee. 

10. A point-of-transaction check service system as recited in claim 9 further 

comprising: 

a financial institution holding said depositing accoimt, to which said amoimt is 
deposited depending upon the result of said convemon, verification or guarantee. 
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1 L A point-of-transaction check service system as recited in claim 9 fiirtiier 
comprising: 

a telecommiinicatioiis network used for coroimiBications between said host 
computer, said switch computer and said draw^ee computer that provides online, real-time 
communications between said computers. 

12. A point-of-transaction check service system as recited in claim 9 wherein said 
drawee computer is further arranged to perform conversion only, conversion with 

verification or conversion with guarantee based upon said transaction information. 

13. A point-of-transaction check service sj^tem as recited in claim 9 wherein said 
drawee computer is further arranged to receive said checking ^count information 
unparsed and to pai^e said checking account information to obtain a transit routing 
niraiber and an account number of the customer, whereby parsing occurs reUably at a 
drawee bank and not at said device means, 

14. A point-of-transaction check ser\dce system as recited in claim 9 fiuther 
comprising: 

a service request message delivered to said switch computer wMch includes said 
transaction information and an indication of whether conversion only, conversion with 
verification or conversion with guarantee is desired. 

15. A point-of-transaction check service system as recited in claim 14 wherein said 

service request message includes a settlement code indicating how settlement will occur, 
thereby accommodating any customer bank and any type of service request. 
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16. A point-of-transaction check service system as recited in claim 1 4 -^^lerein said 
service request message includes a unique transaction identifier that ties together related 
transactions in a transaction set. 

17. A method of performing a transaction at a point of sale, said method comprising: 

a step for performing the function of receiving checking account information from 
a paper check of a customer; 

entering an amount of said transaction into a terminal; 

assembling a service request message that includes said choking account 
infomiation, said amount and a request to perforai conversion only, conversion with 
verification or conversion with guaranty; 

sending said service requ^t message to a switch computer arranged to receive and 
to further route said service request message; 

receiving a response message via said switch computer indicating a response to 
said request to perform conversion only, conversion with verification or conversion with 
guarantee; and 

retiraiing said paper check to said customer, said paper check not being used as a 
negotiable instrument. 

18. A method as recited in claim 1 7 wherein said step for performing the function of 
receiving includes: 

swiping a paper check of a cuistomer through a device to obtain raw magnetic ink 
character recognition (MICR) information from said check, 
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19. A method as recited in claim 17 ftirther comprising: 

perforaiing said steps of sending and receiving over a teiecommiinications 
network that provides online, real-time commimications, whereby said customer at said 
point of sale waits a reasonable time for said response message. 

20. A method of processing a paper check transaction occurring at a point of sale, a 
monetary amount originating at said pomt of sale and said paper check providing 
checking account information, said method comprising: 

receiving a ser\dce request message from said point of sale, said service request 
message including said checking account information, said monetary amount .and a 
request for a type of check service; 

detemiining whether a portion of said checking account information matches with 

one of a plmality of participating banks; 

determining whether said request for a type of check service matches with a 
service provided by one of said banks; 

determining where to route said service requ^t message; 

sending said service request message to an authorizing institution that is equipped 
to handle said request for a type of check service; 

receiving a response message to said service request message from said 
authorizing institution; and 

sending said response message to said point of sale indicating the result of said 
request for a type of check service, whereby said paper check is not used as a negotiable 
instrument and is returned to said customer. 

21. A method as recited in claim 20 ftirther comprising: 
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performing said steps of receiving and sending over a telecommnjodcations 
network that provides online, real-time communications, whereby said customer at said 

point of sale waits a reasonable time for said response message. 

22. A method as recited in claim 20 wherein said request for a type of check service 
includes a request for conversion only, conversion with verification or conversion with 
guarantee. 

23. A method as recited in claim 20 mdierein said checkmg accoimt information is 
received in raw MCR data format and is sent to said authorizing institution in order to 
parse said checking accoxmt information to obtain a transit routing number and an account 
number of the customer, whereby parsing occurs reliably at an authorizing institution and 
not at said point of sale, 

24. A method as recited in claim 20 further comprising: 

adding a settleniCTit code indicating how settlement will occur to said service 
request message, thereby accommodating any customer bank and any type of service 
request. 

25. A method as recited in claim 20 fiirther comprising: 

adding a unique transaction identifier to said service request message, thereby 
tying together related transactions in a transition set. 
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Receipt Example 

Merchant Name 
Merchant Address 

Merchant Phone 
Date: 04/04/00 
Time 1 1 :56 
Lane #99 

Cashier #7777 

AMOUNT OF TRANSACTION: $82.35 



AMOUNT OF SALE: $62.35 
CASHBACK: $20.00 

Routing # 122101191 
Account # XXXXXX4587 



Check # 1234 



Customer's Bank: (optional) 

AUTHORIZATION AGREEMENT: 

I authorize the merchant to use the Information from my 
check to initiate an Electronic Fund Transfer {EF I ) or a 
paper draft to debit my bank account for the amount of 
the transaction, i acknowledge and agree that the 
merchant-initiated EFT is not a check transaction, and 
is cDverned by applicable EFT law. In the event that 
the EFT or draft is returned unpaid, 1 understand and 
agt ee that the merchant may charge a return fee to my 
bank account. 

X 

Authorization Signature 

Customer Service Number 

Top Copy - Merchant 
Bottom Copy - Customer 
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